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APOLLO EXPERIENCE REPORT 

FLIGHT-CONTROL DATA NEEDS, TERMINAL DISPLAY DEVICES, 
AND GROUND SYSTEM CONFIGURATION REQUIREMENTS 

By Richard A. Hoover 
Lyndon B. Johnson Space Center 

SUMMARY 


The successful accomplishment of the Apollo Program objectives depended to a 
large extent on the mission control and monitoring provided by the flight-control team 
located in the mission control center at the NASA Lyndon B. Johnson Space Center (for- 
merly the Manned Spacecraft Center). Therefore, a major flight-operations activity has 
been the development of flight -control facilities. These facilities are viewed by the user 
organization in terms of data needs, the selection of ground-based display and control 
systems, and the management of the configuration of these systems to meet the data 
needs. The relationships between certain program factors and this development, selec- 
tion, and management process are reviewed in this report. 

The most significant Apollo Program factors are the developmental nature of the 
flight program, the number of mission phases, the level of activity in each mission 
phase, the number of vehicles, and the launch intervals. The sizing and loading of the 
ground-based systems were affected by all these factors. However, the two concepts 
significant in reducing the sensitivity of the ground-based systems to these factors were 
based on establishing a balance between general-purpose and special-purpose display and 
control systems and displaying a small amount of data with rapid access to all other data. 
The configuration- requirement leadtimes were also dependent on all the factors, espe- 
cially the launch interval. Long leadtimes for configuration requirements combined with 
short launch intervals represented a major problem in configuration-requirement man- 
agement. Two methods are recommended for leadtime reduction without compromising 
flight-control effectiveness. 


INTRODUCTION 


This report covers experience gained during the Apollo Program with the ground 
system used to support the flight-control function. The concept of centralized control 
has been applied to every manned space flight program since Project Mercury, but the 
ability to achieve centralized control from a facility standpoint has been limited by the 
worldwide communications bandwidth and reliability constraints. Because of these con- 
straints, manned sites equipped with voice and teletype communications to the mission 



control center (MCC) were used extensively during Project Mercury and the Gemini Pro- 
gram. If time permitted, all decisions and actions were approved by a centralized 
mission-control team located in the MCC; the remote-site team relayed decisions and 
implemented approved actions. However, if time did not permit, the remote-site team 
could take action and make decisions based on mission rules that were established pre- 
mission. Early in the Apollo Program, the approach of centralized control included 
both manned and unmanned remote sites. This dual approach necessitated two unique 
sets of remote- site computer programs. The programs for the unmanned sites provided 
high-speed telemetry and tracking data to the MCC and command control of the space- 
craft from the MCC, where reliable communications could be provided. The programs 
for the manned sites provided displays of telemetry and tracking data and local command 
control to flight-control personnel located at the site. This approach imposed a heavy 
program -development, checkout, and maintenance workload. The results were elimi- 
nation of many desirable requirements, late delivery of the programs to the sites, and 
degraded reliability. When communication satellites became operational before the 
Apollo 5 mission, reliable worldwide communications were available; therefore, manned 
remote sites were eliminated for the remainder of the Apollo Program. 


FLIGHT-CONTROL DATA NEEDS 


The instantaneous bandwidth of the combined vehicle telemetry downlinks (i. e. , 

100 to 200 kbps) greatly exceeded the flight-control data needs; therefore, the concept 
of "display a few parameters at a time with rapid access to all others" was adopted and 
applied to the data flow from the remote sites to the MCC and to the data display in the 
MCC. The data-flow system provided a library of data-flow formats (each format con- 
taining a maximum of 2. 24 kilobits of vehicle telemetry data) from the remote sites to 
the MCC (table I). The formatting technique used was a combination of vehicle selection, 
parameter selection, and sample-rate reduction techniques. 

During the first few Earth-orbital missions, involving only a booster and either 
the command and service module (CSM) or the lunar module (LM), only one high-speed 
data format at a time was required from each remote site. During the lunar missions, 
the need was increased to two simultaneous high-speed data formats from each remote 
site. This change was a result of the two new high-activity phases: the lunar-landing 
and the lunar-launch phases, in which both the CSM and LM were active. High-speed 
data-format- selection control was exercised from the MCC. 

The concept of "display a few parameters at a time with rapid access to all others" 
was also applied to the computer-driven television (TV) displays. The parameters that 
were available from high-speed data formats at the MCC were placed on computer -driven 
TV display formats so that only a few display formats had to be displayed at a given time. 
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TABLE I. - DATA-FLOW FORMAT CONSTRAINTS 




Format name 

Vehicle format bit rate, bps 

SLV a 

CSM 

LM 

SLV/CSM backup 

1075 

1075 

0 

SLV launch 

2150 

0 

0 

LM only 

0 

0 

2240 

CSM and LM PCM b (no OBC 0 ) 

0 

950 

1150 

CSM and LM backup 

0 

1050 

1150 

CSM maneuver and LM coast 

0 

1600 

640 

CSM only 

0 

2240 

0 

CSM PCM only (no OBC) 

0 

2240 

0 

j 

SPS burn 

0 

2240 

0 

LM maneuver and CSM coast 

0 

420 

1820 

Erasable memory dump 

0 

(e) 

(e) 

SLV orbit 

2150 

0 

0 

CSM only (Program 22) 

0 

2240 

0 

OBC data 

0 

420 

1820 


a Saturn launch vehicle. 

Pulse code modulation. 

Onboard computer. 

Service propulsion system. 

0 

Optimum manner of formatting determined by implementing organization. 
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SELECTION OF TERMINAL DISPLAY DEVICES 


Balance of General-Purpose and Special-Purpose 
Display Devices 


The concept of a general-purpose display device such as TV was adopted to allow 
large variations in display-presentation techniques and to provide access to large 
amounts of data in a small console area. The limitations of any general-purpose device 
for special applications were recognized. Therefore, the general-purpose devices were 
augmented by the use of special-purpose display devices to provide such characteristics 
as high sample rate, high accuracy, attention getting, and time histories. This concept 
of a balance between general-purpose and special-purpose display devices was very 
useful in both the Gemini and Apollo Programs. The choice of what balance to use is 
subjective and is sensitive to the nature of the program being run and to the level of ex- 
perience with similar functions. As an example of the effect of the experience level, 

CSM systems monitoring was very similar to previous manned spacecraft monitoring; 
therefore, the general-purpose TV displays were used extensively. However, scientific- 
experiment operation for the Apollo lunar surface experiments package (ALSEP) was new 
to flight control, and unique special-purpose display devices (i. e. , drum recorders, 
multipoint recorders, and meters) were used for experiment-data presentation. As ex- 
perience is gained with scientific -experiment operation, an additional category of 
general-purpose display devices may be added to the current display system. 


General-Purpose Display (Television) 

The TV display system is the prime general-purpose method of display within the 
MCC. Analysis of required display characteristics such as clarity and density of data 
presentation, data sources, distribution of displays, and hardcopying of the data resulted 
in the choice of the high -resolution TV technique. This selection was based on the ease 
of distribution and on the types of input information to the display system. Of the five 
categories of inputs, four were scenic. The inputs are as follows: 

1. Computer-driven displays (the only nonscenic type) 

2. Opaque televiewers (cameras mounted over tables in remote locations within 
the MCC and used for such manually prepared information as trend plots, drawings, 
and Flight Plan revisions) 

3. External TV (Kennedy Space Center launch TV and spacecraft TV) 

4. Reference slide files 

5. Other cameras within the MCC 

These sources are routed through a switching matrix to provide outputs to individ- 
ual console TV monitors, ceiling-hung TV monitors, and large projection group-display 
monitors. Of these various input sources, the computer -driven displays and the opaque 
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televiewers are the most useful. External TV provided a significant addition for the 
launch and spacecraft TV camera presentations. The reference slide file, designed to 
provide rapid access to document storage, was of little use because of the constraints 
placed on text data (i. e. , information could not be taken from existing documentation be- 
cause special text formatting was necessary for TV presentation) . 

The categories of computer-driven display formats are alphanumeric tabulations, 
X-Y and time-history plots, meter representations, and schematic and dynamic digital- 
data combinations. The alphanumeric tabulations, X-Y plots, and time-history plots 
have been used extensively and are considered the most adaptable type presentation for 
computer-driven TV. The meter representations were eventually deleted from the 
system because of the poor quality of the display formats. Presentation by a schematic 
that included dynamic digital data was tried on several occasions. This category proved 
to be satisfactory from a data-presentation standpoint; however, reconfiguration of the 
category was very costly when compared to the cost for alphanumeric tabulations. 
Therefore, this category should not be considered as a standard format category and 
should be used only in special cases. 

During the Earth-orbital flights of the Apollo Program, a complement of 
28 computer-driven TV channels was sufficient. However, expansion to 36 channels was 
required for the Apollo lunar-landing missions. 

Two control modes were provided for the TV display system. The capabilities are 
discussed in the following sections. 

Display request mode. - An individual console may request a display format; the 
computer generates the data, formats the display, outputs the data to the next available 
computer-driven TV channel, and automatically connects that channel to the TV monitor 
of the requesting console. The concept of a computer-driven channel assignment was 
based on a "first come, first served" basis as opposed to consigning channels to displays 
or consoles. Initially, difficulties were experienced when all channels were being used 
and additional critical displays were needed. To provide positive control, a new display 
format was added to identify which display format was on each channel and to identify 
which console had requested the display. Through the use of this display, the flight- 
control team could determine which display formats to release to the proper channels. 

Channel attach mode. - In the channel attach mode, a console requests a given TV 
channel and receives whatever data are on that channel. This concept of sharing TV 
channels has been very workable and has resulted in the need for significantly fewer 
channels . 

A hardcopy subsystem was included as part of the TV display system. The re- 
quirements for this subsystem were the same as for TV display (i. e. , hardcopy of both 
data and scenic-type displays). This subsystem has been unsatisfactory because of poor 
legibility. Experience gained during the Apollo Program has proved that only computer- 
driven data displays need to be hardcopied and, therefore, that the scenic hardcopy re- 
quirement could be eliminated. This would make possible the use of many existing direct 
computer printout/plotting devices instead of the current TV photographic -hardcopy 
subsystem. 
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Special-Purpose Display Devices 

Event modules . - The event module is a special-purpose display device used exten- 
sively on consoles. Initially, events were grouped 18 and 36 events per module. The 
initial concept was to provide only those events on event modules that were applicable 
to all mission phases; all other event displays were to be provided by the use of the 
computer-driven TV system because these displays can be released when not in use. 
However, experience showed that few events met this criterion; therefore, the evolution 
of the use of event modules during the Gemini and Apollo Programs resulted in the cur- 
rent concept that the prime method of event display is the use of event lights. This 
concept change caused a significant increase in the size of the event-display hardware 
and software, including the development of 72-event modules for high-density event dis- 
play. Because the original system was designed for expansion, no significant problem 
was encountered. Event-light modules are used extensively, both in the mission oper- 
ations control room (MOCR) for prime-parameter monitoring and in the staff support 
rooms for detail-parameter monitoring. The two sources of event drives are the real- 
time computer complex (the same computer that drives the computer-driven TV chan- 
nels), which is required for parameters that must be processed or limit sensed at a 
rate no greater than once per second; and a pulse- code-modulation (PCM) ground station, 
which is required for high-sample-rate event displays. In the early phases of the Apollo 
Program, event displays directly from the ground station (i. e. , bypassing the computer) 
were also desired because of a lack of confidence in inline computer systems. 

Anal og strip- chart recorders . - The analog strip-chart recorders were used pri- 
marily for detailed analyses of system parameters (especially those requiring high sam- 
ple rates); therefore, the recorders were in the staff support rooms. These recorders 
also bypassed the computer and were driven directly out of the PCM ground station. 

Two strip-chart recorders used in the flight dynamics staff support room (SSR) were an 
exception because they were used to display guidance parameters that had to be processed 
by the real-time computer complex. These two strip-chart recorders were viewed by 
TV; the pickup cameras viewed the strip-chart recorders directly. This TV method of 
display was very useful and was extended to ALSEP scientific parameters (i. e. , X-, Y-, 
and Z-axes of the lunar seismometer). More extensive use of TV for the display of an- 
alog parameters as a function of time is anticipated. The two methods of TV presenta- 
tion of analog display investigated for the remainder of the Apollo Program were the use 
of TV-viewing strip-chart recorders for high-sample-rate presentation and the use of 
computer-generated time-history plots. 

Analog meters . - Experience in the use of analog meters as an end-display device 
has been interesting, and several conclusions can be made. Initial attempts were made 
to depict meter-type displays on the computer-driven TV displays. As mentioned in the 
TV discussion, this method was unsatisfactory and, because proportionately large 
amounts of computer capacity were required, the method was discontinued. The use of 
hardware meters increased immediately after the elimination of meter representations 
on computer-driven TV displays. These hardware meters were driven directly from 
the PCM ground stations by digital-to-analog converters. A common rationale was used 
regarding the hardware meters, the event-light panels, and the strip-chart recorders. 
Initially, the users had little confidence in computer-driven displays; therefore, meters 
driven by the PCM ground station provided a backup to the computer-driven displays. 

As confidence in the computer displays increased, the number of hardware meters was 
reduced. The change in meter number and location as the Apollo Program progressed 
exemplified this increase in confidence. For the AS-201 mission in February 1966, 
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which was a Saturn-IB (S-IB) launch-vehicle-only mission, 30 meters were in the MOCR. 
For the Apollo 5 mission in January 1968, which involved an S-IB launch vehicle and an 
unmanned LM, the number of meters had increased to 49. For the Apollo 6 mission in 
April 1968, which involved a C5 launch vehicle and an unmanned CSM, a maximum of 
68 meters was reached. At this time, a strong trend developed to move the meters 
from the MOCR to the staff support rooms. By the time of the Apollo 13 mission in 
April 1970, only 43 meters were left when all vehicles were required. 

In summary, the following conclusions can be made about meters. Early in the 
Apollo Program, heavy reliance was placed on meters because of lack of confidence in 
computers. As the number of vehicles increased during the early missions, the number 
of meters increased proportionally. Midway through the program, a shift was noted; 
most of the meters were relegated to the staff support rooms for detail analysis. This 
shift represented an increase in reliance on the computer -driven TV displays. Finally, 
a reduction in the number of meters occurred as the staff support rooms relied on the 
computer-driven TV displays. The last prime use for meters in the Apollo system was 
for the detailed monitoring of the Saturn launch vehicle, a short-lived, highly active 
system. 

Projection-plotting devices . - The projection -plotting devices were implemented 
during the Gemini Program. Standard, direct-write X-Y plotboards were used as 
backup devices because the projection-plotting devices were a developmental system. 

The backup direct-write plotboards were removed early in the Apollo Program after the 
projection-plotting devices became operational. The projection-plotting devices were 
used primarily for trajectory displays (e. g. , velocity as a function of flight-path angle 
plots with limit lines) . The devices were also used as general-purpose displays to de- 
pict the mission progress (i. e. , the relative location of the spacecraft during translunar 
coast) . 

Event recorders. - Event recorders provided accurate high-sample-rate time 
histories of events. Initial implementation for the Apollo Program was a 200-event pen 
capability in a remotely located equipment room. By the time of the Apollo 11 mission, 
verification of event occurrence in a time-dependent manner became a necessary task 
of the vehicle systems SSR; therefore, an additional 400- event pen capability was added 
in the vehicle systems SSR. These recorders were not collocated with the consoles be- 
cause of floor space constraints. Recorder utility would have been improved if the re- 
corders and consoles had been collocated; however, collocation was not considered 
mandatory because most of the events were duplicated on the console event lights and 
the computer -driven TV formats. 

Unique display devices. - A unique cardioscope display module was used for pres- 
entation of astronaut heart waveforms. The cardioscope was chosen instead of the TV 
because of the high accuracy of waveform that was required. The cardioscope paralleled 
the same information on strip-chart recorders in the medical SSR. Heart and respira- 
tion rates were presented on special-purpose digital-read-out modules as part of a unique 
input-computation system for the flight surgeon. A third category of unique display de- 
vices was the event-sequence-override module. The use of these modules was discon- 
tinued because many spacecraft systems had different event sequences depending on the 
mode of system operation. Computer-driven TV was used where event sequences were 
of interest. The need to override telemetry events diminished as confidence in the 
spacecraft and ground telemetry systems improved through the use of cross-checking of 
different parameters. 
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MANAGEMENT OF GROUND-SYSTEMS CONFIGURATION 


As used in this report, configuration requirements refer to the specification of the 
arrangement of the ground-systems data formats, displays, and controls. Because of 
the developmental nature of the Apollo Program and the short launch intervals, require- 
ments were levied against the ground systems to provide various degrees of configuration 
flexibility from mission to mission. Therefore, the configuration requirements were 
constrained to be within the configuration capability of the original ground system design. 


Configuration-Requirement Categories 

Configuration requirements were divided into six categories based primarily on 
the leadtime needed for the reconfiguration of each category. 

1. Callup of remote site facilities and interfaces 

2. Data-flow format configuration (i. e. , the parameters and sample rate in each 
format, within the constraints given in table I) 

3. Special data processing of a mathematical nature (e. g. , the determination of 
the fuel volume from pressure and temperature telemetry measurements) 

4. Command-system configuration (e. g. , the command- execute panel arrange- 
ment and the identification of which commands are to be stored in the remote-site com- 
puters for mission execution) 

5. Display-system configuration (e. g. , the layout of the computer-driven TV 
display formats and the arrangement of parameters on event panels, meters, and 
recorders) 

6. Intercommunication panel configuration (e. g. , access to the various loops and 
loop arrangement on the panels) 


Documentation Method 

The method of documenting the configuration requirements evolved from a method 
of writing the requirements in text form, as was done in Project Mercury, to a hybrid 
method of computer-generated/manual text preparation. The use of computer-generated 
documentation was valuable where many configuration changes were caused by a devel- 
opmental flight program such as the Apollo Program (i. e. , early missions had few ve- 
hicles and simple mission profiles, whereas later missions included more numerous 
and more highly developed vehicles and complex mission profiles). Three advantages 
of the computer-generation method were as follows. 

1. The computer could sort the requirements efficiently. (The requirements were 
prepared according to flight-control function, such as all configurations applicable to 
the CSM guidance function, whereas the implementing organization preferred grouping 
requirements by system, such as all data-flow configuration requirements.) 


8 



2. The changes from previous mission configurations were identified easily. 


3. Maximum use was made of previous mission-configuration requirements with- 
out having to retype and check the unaffected configurations. Manual text preparation 
was still required for the specification of new or modified special data-processing 
requirements. 


Single-Point Coordination, Review, and Approval 

Configuration-requirement management was accomplished by one flight -control 
organization. The responsibilities of this organization were to ensure that schedules 
were met, policies were applied, requirements were integrated, duplication was avoided, 
requirements were within the capability of the systems, and late requirements were 
evaluated from a standpoint of justification and impact. 


Schedules 

The schedule for submittal of configuration requirements began with the initial 
submittal 10 months before the mission. Final cutoff dates were spaced between 
9 months and 1 month before the mission, depending on the requirement category. 
(Changes t.o the data-flow formats were terminated at 9 months premission, changes to 
special data-processing requirements were terminated at 8 months premission, and all 
configurations were terminated at 1 month premission.) Generally, these requirement 
cutoff dates were a result of the leadtime necessary to implement and check out that re- 
quirement category; however, the last date at 1 month premission was to ensure that 
training integrity was not affected by changing the system configuration. 

The most significant configuration-requirement problem experienced during the 
Apollo Program was the long leadtime associated with three requirement categories. 
These categories were the most important ones from a vehicle-systems-monitoring 
standpoint (i. e. , data-flow format configuration at 9 months premission and special data 
processing and computer-driven TV displays at 8 months premission). The most sig- 
nificant factor causing the long leadtimes was the design approach applied in the ground- 
systems software programs. Although the design approach provided for mission-to- 
mission reconfiguration, extensive program checkout also was necessary to ensure 
reliability. Three additional Apollo Program factors combined with the long leadtime 
to cause many requirements to be eliminated or delayed until later in the program. 

These three factors were the short launch interval between missions, the large volume 
of requirements, and the late changes to the flight vehicles or mission profiles after the 
ground-system-requirement cutoff dates had passed. As experienced during Project 
Mercury and the Gemini Program, a large volume of configuration changes occurred. 
This occurrence is characteristic of a developmental program wherein each successive 
flight is more complex than the preceding one, and the program includes different mis- 
sion profiles and vehicles. Generally, the requirements that were eliminated or delayed 
until later in the program had less than mandatory justification. Late mandatory re- 
quirements consumed a large portion of the available manpower and computer-hour re- 
sources because of extensive coordination and retesting. Consequently, even more 
nonmandatory requirements often were eliminated or delayed, and flight-control pro- 
cedures in turn were changed late in the premission preparation and training cycle. 
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CONCLUDING REMARKS 


The development of both manned and unmanned remote-site computer programs 
caused an excessive program -development workload. Initially, this excessive workload 
resulted in deficient program content and reliability. When the communication satellites 
provided reliable worldwide coverage, the manned remote sites were eliminated; the 
result was highly reliable and satisfactory remote-site programs. The concept of "dis- 
play only a few parameters with rapid access to all others" proved to be both feasible 
and desirable. The amount of data that had to be monitored simultaneously and, there- 
fore, the sizing of the data processing, control, and display systems were proportional 
to the number of vehicles that were active simultaneously. The number of hardware dis- 
play devices required to back up the computer-driven displays was inversely proportional 
to the level of experience the user organization had in using computer systems. A strong 
trend toward computer -driven displays occurred as experience and confidence were 
gained. This trend resulted in a significant improvement in the ability to monitor the 
mission. 

The concept of a balance between general-purpose and special-purpose display de- 
vices was valid. As the size of the total display system was increased, the balance was 
maintained with a slight shift in favor of the general-purpose devices. When new 
mission-control functions were introduced (e.g. , scientific-experiment operations), the 
shift was strongly toward special-purpose display devices; however, as experience was 
gained, the shift reversed in favor of the general-purpose devices. The choice of tele- 
vision as the general-purpose display system provided excellent flexibility of real-time 
information-presentation techniques, data sources, and display distribution. An addi- 
tional type of general-purpose display device oriented toward near-real-time and history- 
information display (i. e. , microfilm) was considered. An evaluation of television 
display sources indicated that the most useful sources were the computer-driven displays 
and the opaque televiewer, whereas the reference slide file was unsatisfactory because 
of unique formatting constraints that were incompatible with standard documentation. 

An evaluation of television display format techniques indicated that alphanumeric 
tabulations and plots were most useful. A systems schematics presentation with dynamic 
digital data was a good presentation technique, but its reconfiguration was costly. 

Because the meter pictorial technique was unsatisfactory, it was discontinued. The two 
methods of computer-driven television display access (display request and channel 
attach) operated well and reduced the size and cost of the display system. The require- 
ment to hardcopy scenic television displays resulted in an unsatisfactory hardcopy 
system. Experience has shown that the elimination of this requirement is acceptable 
and facilitates the use of existing high-quality direct computer printout/plotting devices. 

The application of computer-generated documentation to configuration requirements 
was beneficial in the Apollo Program and is expected to be beneficial for any complex 
developmental flight program. The coordination, review, and approval of configuration 
requirements by a single-point operations organization was appropriate to a developmen- 
tal flight program such as the Apollo Program. However, the benefits of computer- 
generated documentation and the advantages of configuration- requirement management 
by a single-point operations organization would be reduced greatly for an "all-up" pro- 
gram such as Sky lab. 
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A large volume of configuration- requirement changes should be anticipated in any 
developmental flight program. The long leadtimes for configuration requirements were 
a significant problem in the Apollo Program. The leadtime is dependent on the initial 
design approach. Increased emphasis should be placed on this factor (i. e. , rapid re- 
configuration, especially in the software systems) during the systems -design phase of 
future flight programs. Two concepts tried in the Apollo Program are applicable: the 
modular or table fill-in approach, which reduces or eliminates the need for extensive 
program checkout after each reconfiguration; and the "universal" design approach, which 
does not require reconfiguration (e.g. , the manual-select keyboard for television 
display access and the digital-select matrix for the universal command system). 


Lyndon B. Johnson Space Center 

National Aeronautics and Space Administration 
Houston, Texas, January 30, 1974 
956-22-00-00-72 
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